Ask Your Question
0

OS X Monterey / IP ID 0x0000

asked 2022-02-18 23:48:52 +0000

Stuart Kendrick gravatar image

updated 2022-02-19 00:16:39 +0000

I'm analyzing a pcap capturing everything that an OS X box (running some recent flavor of Monterey) is producing ... and I notice that this stack mostly sets IP ID i to 0x0000. Sometimes, it starts incrementing by 1, e.g. 0x0000, 0x0001, 0x0002, 0x0003 ... but it generally doesn't get far before it returns to 0x0000 At the moment, I'm filtering on tcp.port==443

I haven't seen this behavior -- I'm used to seeing IP ID number increasing steadily, then wrapping at 0xFFFF and starting over

Would anyone care to speculate as to why an OS might not want to bother setting IP ID? Thinking about this, I suppose a non-zero IP ID is not essential to the success of a conversation ... it is only needed for IP fragmentation, and the Do not Fragment bit is set in these frames ... but it seems odd to me

--sk

Stuart Kendrick

edit retag flag offensive close merge delete
add a comment

1 Answer

Sort by ยป oldest newest most voted
0

answered 2022-02-19 03:23:31 +0000

Jim Aragon gravatar image

updated 2022-02-19 03:25:00 +0000

RFC 6864, "Updated Specification of the IPv4 ID field," in section 4 defines "atomic datagrams" as "datagrams not yet fragmented and for which further fragmentation has been inhibited." That is, further fragmentation has been inhibited by setting the Don't Fragment bit. So, they haven't been fragmented and they won't be fragmented. In section 4.1 it states "In atomic datagrams, the IPv4 ID field has no meaning; thus, it can be set to an arbitrary value...."

So, there are some IPv4 hosts that continue to increment the IP ID field in atomic datagrams, regardless of the fact that the field is meaningless in those packets, and, as you see, there are other hosts that just put zero in the IP ID field. They can put any value, but if they aren't going to increment to the next IP ID value, they generally put zero.

All IPv4 hosts are required to handle IP datagrams of at least 576 bytes, so IP datagrams that are 576 bytes or less also will not be fragmented, regardless of whether the Don't Fragment bit is set or not, so some hosts will also put zero in the IP ID field if the packet is 576 bytes or less, although that case is not discussed in RFC 6864.

Technically, an atomic datagram is defined in RFC 6864 as: The Don't Fragment bit is set, the More Fragments bit is not set, and the Fragment Offset is 0.

edit flag offensive delete link more

Comments

Small correction to the following:

All IPv4 hosts are required to handle IP datagrams of at least 576 bytes, so IP datagrams that are 576 bytes or less also will not be fragmented

RFC 791 states:

All hosts must be prepared to accept datagrams of up to 576 octets (whether they arrive whole or in fragments).

So, these datagrams can be fragmented, but generally won't as the MTU of most links is large enough to pass them unfragmented.

SYN-bit gravatar imageSYN-bit ( 2022-02-20 09:33:58 +0000 )edit

I see. So since the IP Ident field is not required for frames flagged as Don't Fragment, some stacks set it to an arbitrary value, like 0x0000, disappointing network analysts like myself but nevertheless RFC-compliant

Thank you

--sk

Stuart Kendrick gravatar imageStuart Kendrick ( 2022-02-21 12:26:37 +0000 )edit
add a comment

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools

1 follower

subscribe to rss feed

Stats

Asked: 2022-02-18 23:48:52 +0000

Seen: 510 times

Last updated: Feb 19 '22